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I. Real Party in Interest. 

The real party in interest for the present application is Convergys Information 
Management Group, Inc. It received an assignment, dated October 8-9, 2003, ftom the 
inventors, Ian James Clubb, Philip Geoffrey Claridge, Thomas Joseph Shusta, and Jeffrey Miller, 
of the application, which is recorded at Reel/Frame 015060/0423. 
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II. Related Appeals and Interferences. 

To the best of Applicant's knowledge, there are no appeals or interferences which would 
directly affect, or be directly affected by, or have a bearing on the Board's decision in the present 
appeal of the final rejection of application 10/682,663, filed October 9, 2003. 

Applicant notes, however, that there are several related applications pending within this 
family including, but not limited to, Serial No. 10/682,601 (S/M for Work Management)(non- 
final action mailed November 4, 2009) and Serial No. 1 1/555,518 (Architecture for a System and 
Method for Work and Revenue Management)(request for reconsideration after non-fmal 
rejection filed November 13, 2009). 
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III. Status of the Claims. 

Claims 1-22 were originally filed in the present application. 

Claim 23 was added. 

Claims 1-23 have since been canceled. 

Claims 24-41 were added and are the subject of the present appeal and are set forth in the 
Appendix (VIII) of this Brief 



09/944,676 



IV. Status of Amendments. 

Prior to the most recent office action, concerning this application, a final rejection mailed 
June 25, 2009 (the "Final Rejection"), in this application, amendments were submitted on 
March 2, 2009, and subsequently entered. No amendments have been submitted in this 
application, after issuance of the Final Rejection. 



09/944,676 



V. Summary of Claimed Subject Matter 

Generally, claims in the present application improve the authorization of transactions. 
Authorization ensures that the paying party has sufficient credit to cover the cost of the event.' 
Often authorization will revolve around the credit-worthiness of the consumer, the amount of 
money available in a particular account, or a specific level of permission granted to that 
consumer,^ 

The present application utilizes a master wallet that is subdivided into independent 
subsets called shadow wallets. The master wallet comprises a usage allowance (resource) 
corresponding to a set of consumer identifiers.^ For example, a company may grant a certain 
level of credit, which may be subdivided amongst individuals or subgroups of the employees 
depending on the preference of the ultimate consumer (i.e., the entity responsible for paying the 
bill)."* The master wallet server may be programmed to create a shadow wallet corresponding to 
at least one of a set of consumer identifiers.^ 

A. Grouping of Claims 

The applicants suggest the following grouping of claims for the present appeal: 

Group I: Claims 24-28 and 31-41. Claim 24 shall represent this grouping. 
Group II: Claim 29-30. Claun 29 shall represent this grouping. 

The arguments for why these groups of claims are separately patentable are set forth m 
detail in the section VII of this brief 

1. Summary of Group I; Claims Referring to Independent Subsets 

The claims consistently refer to an architecture in which "independent subsets of said 
master wallet" [shadow wallets] are associated with a logical server and a logical datastore.^ 
Independent Claim 24 is representative of this claim language. It includes a computerized 

' Application at [0005]. 
^Application at [0021]. 
^ Application at [0030]. 
* Application at [0030]. 
^Application at [0031]. 
^ Application at claim 24 and [0031]. 
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system for resource management in which a master copy of a wallet, called the master wallet, is 
stored in a computer readable datastore^ The datastore is partitioned into a set of logical 
datastores.* The system creates a master wallet for a given set of users and configures the 
logical datastores for a subset of those uses.^ The subsets of the master wallet are called shadow 

wallets and operate independently, '° In fact, referring to Figure 3 (below) each shadow wallet is 
associated with a specific logical datastore (note the allocation of two different shadow wallets to 
two different consumer servers - CS_456 and CS_567). These shadow wallets are subsets of the 
master wallet residing on Wallet Server WS_9876." 
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Figure 3 

Thus, the system can process a request for a given user against the specific shadow wallet 
associated with that user.'^ It furthermore enables the system to monitor usage across all of the 
shadow wallets derived from said master wallet and automatically adjust the usage allowances 
subdivided across said shadow wallets in anticipation of expected future use of said shadow 
wallets.'^ 



Application at [0105, 0108] 
* Application at [0110, 0122]. 
^ Application at [244, 250-255]. 
'"Application [0250]. 

" Application Figure 3-5 and Figure 24 and 48A. 

Application [0234]. 
" Application [0179, 0408-0415] and Figure 30. 
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2. Summary of Group 2; Claims Relating to Borrowing Between Shadow 
Wallets 

The claims also include the ability for the shadow wallets to interact with one another.''^ 
Dependent claim 29 focuses on extending the system by allowing a first shadow wallet to 
"borrow" or "reclaim" a portion of unused usage allowance from a second shadow wallet.'^ 



''' Application, claim 29. 
Application at [0108-0109, 0034]. 
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Grounds of Rejection to be Reviewed on Appeal 

A. Whether claims 24-41 are unpatentable, based on 35 U.S.C. § 103(a) as obvious over 
Allen et al., US Patent No.7,280,645 (hereinafter Allen), in view of Black, US Patent 
No. 7,1 17,172 (hereinafter Black), in further view of Sarcanin, US Patent No. 
6,941,285 (hereinafter Sarcanin). 



-10- 



09/944,676 



VII. Argument 

A. Standard for Prima Facie Case of Obviousness 

It is well settled that the burden of making out a prima facie case of obviousness lies with 
the Examiner."' It is also well settled that part of that prima facie case is showing that all 
limitations are taught or suggested in the prior art.'^ When making the rejection, each word in a 
claim must be considered.'^ If a rejection fails to consider all words in a claim, that rejection 
should be reversed.'^ 

B. High-Level Description of Cited Art 

As historical background, in prior office actions for this Application, the Examiner cited 
both Black and Allen. Black describes proactively adjusting account balances. It was not cited 
as a reference for the limitations argued in this Appeal. Allen discloses dividing a master 
account on a per call basis, as requests are received, as opposed to dividing the master account 
among multiple users. The Examiner based the current Final Rejection on both Allen and 
Sarcanin. 

C. Group I - Argument Regarding the Flaw of Examiner's Rejection in Claim 24 

1. The Cited Art Does Not Disclose Allocation of Independent Subsets 
The rejections of claims 24-28 and 31-41 are improper and should be reversed because 
the art cited by the Office does not teach or suggest each limitation in these claims. In particular. 



E.g., MPEP § 2141 H 1 ; /w re Rouffet, 149 F.3d 1350, 1355 (Fed. Cir. 1998) ("to reject claims in an application 
under section 103, an examiner must show an unrebutted prima facie case of obviousness"). 

E.g., Ex parte Wada, Appeal No. 2007-3733 (BPAI 2008) ("When determining whether a claim is obvious, an 
examiner must make 'a searching comparison of the claimed invention - Including all Its limitations - with the 
teaching of the prior art.' In re Ochiai, 71 F.3d 1565, 1572 (Fed. Cir. 1995) (emphasis added). Thus, 'obviousness 
requires a suggestion of all liinitations in a claim.' CFMT, Inc. v. Yieldup Intern. Corp., 349 F.3d 1333, 1342 (Fed. 
Cir. 2003) (citing In re Royka, 490 F.2d 981, 985 (CCPA 1974))."). 

In re Wilson, 424 F.2d 1382, 1385 (CCPA 1970) ("All words in a claim must be considered in judging the 
patentability of that claim against the prior art."). 

In re Wilson, 424 F.2d 1382 (CCPA 1970) (reversing a rejection which was based on failing to consider all words 
in a claim). 
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Claim 24, representative of this Group I, recites the following limitation which is not disclosed 
or suggested in the Cited Art: 

allocate a plurality of independent subsets of said master wallet, 
prior to an event arrival including a request, each of said subsets 
hereinafter referred to as a shadow wallet, wherein each shadow 
wallet is associated with one of said plurality of logical servers and 

its associated logical datastore; 

Initially, the Applicants note that, when addressing Claim 24, the Office conceded that 
the "allocating a plurality of independent subsets of said master wallet" is absent from Allen?" 
While the applicants appreciate (and agree with) this concession, the applicants submit that the 
allocation of independent subsets requirement is also absent from Sarcanin, the only other 
reference cited in the rejection of claun 24. 

2. The Office Ignored the Limitation Regarding the Architecture of the 
Independent Subsets 

Furthermore, when rejecting Claim 24, the Office simply ignored the limitation " each 
shadow wallet is associated with one of said plurality of logical servers and its associated 
logical datastore" . This limitation supports the previously addressed limitation regarding the 

"allocation of independent subsets" as it clarifies that each shadow wallet may be individually 
assigned to one out of a plurality of servers/datastores. This architectural feature enables the 
independent fiinctioning of shadow wallets. 

3. Description of Sarcanin 

Sarcanin is primarily focused on security including access rights that may be allocated to 
a specific individual/group. There is some discussion toward the end of Sarcanin about allowing 

a group (either a family or a business) to allocate a certain amount to pre-authorized entities as 
well as allow "a boiTower, as permitted by a shared access agreement, [to] debit a particular 
lender's accoimt." Applicant assumes that the Examiner is focusing on the following clause, in 



Office Action at 4, Section 9. 
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isolation, from Claim 24: "prior to an event arrival including a request" which was added in the 

last response, dated March 2, 2009, in an effort to reach a compromise with the Examiner. 

In support of the Office's Final Rejection, the Examiner cited Sarcanin (49:53 - 50:30) as 

"allocating a plurality of independent subsets of said master wallet, prior to an event arrival 

including a request." But the Examiner did not consider all of the limitations of the claim 

language. Specifically, the cited Sarcanin passage reads as follows: 

VirtualSAFE links or images on participant sites. The VVP service 
may also include a fiind allocation feature which may be entitled 
"VirtualSAFE Trust and Allowance". This feature allows children 
and parents, or any authorized shared person, to relate to one 
another at a different level. Parents who are registered and 
authenticated users of VirtualSAFE may allocate a certain 
amount of prc-authorized spending money per month to their 
children on their credit/debit card. Similarly, businesses or 
friends who are registered and authenticated users of 
VirtualSAFE may allocate a certain amount of pre-authorized 
spending money from their accounts to authorized personnel, 
friends, etc. These values may be added, modified, and authorized 
at the beginning of each month. Consider the following example: 
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Now consider the situation of business-to-business shared accounts 
in which two businesses operate with one another. According to 
agreement, this application allows one business to access the other 
business's account for a preauthorized and predetermined amount. 
A lender opens an account or allows shared access to a borrower. 
Furthermore, this application allows financial transactions 
equivalent to the commercially known line of credit, mortgage 
loan, or loan. Here, a borrower, as permitted by a shared access 
agreement, can debit a particular lender's account using the strong 
authentication provided by VirtualSAFE's Authentication 
Authority or, if necessary, by VirtualSAFE's predefined Attribute 
Authentication Authority. The preauthorized user is able to both 
debit and credit the account as per agreement and policy. The same 
approach may be used for shared-access in a document 
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environment, or application environment, in which one entity (i.e. 
the account holder) may allow another user access for sharing in 
accordance with user definitions and privileges. 

The preauthorized limits of Sarcanin are not the same thing as instantiating an individual 
subset "prior to an event arrival" wherein each subset is associated with a logical 
server/datastore . This is illustrated by Figure 3 of the AppUcation (see, above); the illustrated 
shadow wallets are assigned to different consumer servers which are logically partitioned from a 
master wallet residing on a wallet server,^' 

Indeed, as the portion cited by the Examiner indicates, there are no individual subsets 
(shadow wallets) being allocated at all. Rather, Sarcanin' s method for shared access is based on 
the setting of a predefined Attribute Authentication Authority via a shared access agreement.^^ 

Sarcanin, however, does not provide any disclosure whatsoever regarding the 
instantiation of independent wallets within an architecture including, but not limited to, the 
language " independent subsets of said master wallet, prior to an event arrival including a 
request, wherein each shadow wallet is associated with one of said logical servers and its 
associated logical datastore " of Applicant's Claim 24. [Emphasis added]. Therefore, as set 
forth previously, for a claim to be rejected as obvious, it is necessary, among other things, to 
consider all words in the claim . The Office's rejection of Claim 24 has not met this 
requirement in its treatment of the allocation of independent subsets which are each further 
associated with a logical server/datastore. 



^' Application Figure 3-5 and Figure 24 and 48 A. 

"Here, a borrower, as permitted by a shared access agreement, can debit a paiticular lender's account using the strong 
authentication provided by VirtualSAFE's Authentication Authority or, if necessary, by VirtualSAFE's predefined Attribute 
Authentication Authority." Sarcanin at 50:21-24. 
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D. Group II - Argument Regarding the Flaw of Examiner's Rejection in Claim 29 

a. The Cited Art Does Not Disclose Sharing Among Shadow Wallets 
The rejections of claims 29-30 are improper and should be reversed because the art cited 
by the Office does not teach or suggest each limitation of claim 29, In particular, Claim 29, 
representative of this Group II, recites the following: 

29. A computerized system as claimed in Claim 28 wherein said 
wallet server further comprises computer executable instructions to 
reclaim an unused portion of said usage allowance allocated to a 
second shadow wallet and reallocate said unused portion to 
said first shadow wallet. [Emphasis added]. 

Applicants submit that the reallocation of an unused portion from a second shadow wallet 
to the first shadow wallet is absent from Allen, which was specifically cited against this 
limitation. Accordingly, the Office's rejection of claim 29 (and the rest of the claims in Group II) 
as obvious over the combination of Allen, Black and Sarcanin is improper, as none of those 
references teaches or suggests the reallocation of usage from one shadow wallet to another 
shadow wallet present in Claim 29, 

In support of the Office's Final Rejection, the Examiner cited "at least"^^ Allen (1:51-61) 
as teaching "wherein said wallet server further comprises computer executable instructions to 
reclaim an unused portion of said usage allowance allocated to a second shadow wallet and 
reallocate said unused portion to said first shadow wallet." This section does not teach or 
suggest the subject limitation at all. It reads: 



The Applicant is only addressing the specifically cited section as the Allen reference does not, in any case, 
provide the limitation being argued here as well as for the reason that the Examiner bears the burden of mounting a 
prima facie case of obviousness. This "allocates who has the burden of going fomard with production of evidence 
in each step of the examination process. See In re Rimhart, 531 F.2d 1048, 189 USPQ 143 (CCPA 1976); In re 
Linter, 458 F.2d 1013, 173 USPQ 560 (CCPA 1972); In re Saunders, 444 F.2d 599, 170 USPQ 213 (CCPA 1971); 
In re Tiffin, 443 F.2d 394, 170 USPQ 88 (CCPA 1971), amended, 448 F.2d 791, 171 USPQ 294 (CCPA 1971); In re 
Warner, 379 F,2d 1011, 154 USPQ 173 (CCPA 1967), cert, denied, 389 U.S. 1057 (1968)." MPEP 2142. 
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Nothing in this citation discusses one calling card (which is not, in any case, an 
individual subset of a master wallet or a shadow wallet) borrowing/reallocation/reclaiming 
resource from another calling card. A "predetermined amount of minutes is associated with the 
set of cards". This might be considered the "master wallet" but, as that master wallet is never 
subdivided into individual subsets associated with a specific datastore/server, the only way a 
calling card may be replenished is by borrowing from the master account or by recharging the 
master account. A given calling card may be used to add money to the master account but it 
caimot loan money to another calling card. 

To put this in, perhaps, more familiar terms, this architecture permits the a paradigm 
where a parent (master wallet) might loan money to each of his three children (shadow wallets). 
Child 1 uses up his entire allowance and goes back to the parent to ask for more but they have 
reached their limit and the parent is not willing to loan out any more money. (This is the kind of 
limit discussed in Sarcanin). The architecture of the current Application, however, provides a 
mechanism for Child 1 to still get more money. He can be loaned money from either Child 2 or 
Child 3. 

Therefore, according to the standard, as set forth previously, for a prima facie case of 
obviousness, the Office's rejection of Claim 29 failed to consider the functionality of Claim 29 
which allows one shadow wallet to borrow from another shadow wallet.. 

E. Conclusion 

Accordingly, the Office's rejection of Claim 24 (and the rest of the claims in Group I) as 
well as its rejection of Claim 29 (and the rest of the claims in Group II) as obvious over the 
combination of Allen, Black, and Sarcanin are improper as none of those references teach or 
suggest an architecture which enables the "allocation of independent subsets" or to "reclaim an 
unused portion of said usage allowance allocated to a second shadow wallet and reallocate said 
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unused portion to said first shadow wallet." Thus, the Applicant respectfully requests the Board 
to reverse the rejections of the Office so that this Application might proceed to an allowance at 
the earliest possible date. 



Respectfully submitted, 
/Ria Farrell Schalnat/ 
Clubb et al. 

By 

Ria FaiTell Schalnat Reg. No. 47,058 

Attorney for Applicants 

FROST BROWN TODD LLC 

2200 PNC Center 

201 East Fifth Street 

Cincinnati, Ohio 45202 

(513) 651-6426 
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VIII. CLAIMS APPENDIX 

24. A computerized system for resovirce management comprising: 

a. a computer readable datastore associated with a server, said server hereinafter 
referred to as a wallet server, wherein a master copy of a wallet comprising 
computer readable storage representing a usage allowance, hereinafter master 
wallet, is stored; 

b. a plurality of logical servers which are logical partitions of said wallet server; 

c. a plurality of computer readable logical datastores which are logical partitions of 
said datastore; 

wherein said wallet server fiirther comprises computer executable instructions to: 

- create said master wallet for a set of users; 

- configure each of said plurality of logical servers and their associated logical 
datastores for a subset of said set of users; 

- allocate a plurality of independent subsets of said master wallet, prior to an 
event anival including a request, each of said subsets hereinafter referred to 
as a shadow wallet, wherein each shadow wallet is associated with one of 
said plurality of logical servers and its associated logical datastore; 

- configure each of said plurality of logical servers, to process said request 
received by said system for a given user from said subset of users against 
said shadow wallet associated with said given user; 

- monitor usage across all of the shadow wallets derived from said master 
wallet and automatically adjust the usage allowances subdivided across said 
shadow wallets in anticipation of expected future use of said shadow 
wallets. 
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25. A computerized system as claimed in Claim 24 wherein said wallet server further comprises 
computer executable instructions to configure said logical servers to notify said wallet server as 
the usage allowance allocated to a given shadow wallet is consumed. 

26. A computerized system as claimed in Claim 25 wherein said wallet server further comprises 
computer executable instructions to create an additional shadow wallet. 

27. A computerized system as claimed in Claim 26 wherein said wallet server further comprises 
computer executable instructions to reallocate said master wallet across said shadow wallets 
associated with said master wallet. 

28. A computerized system as claimed in Claim 27 wherein said wallet server further comprises 
computer executable instructions to 

a. configure a given logical server to automatically request an additional usage 
allowance when a first shadow wallet reaches a predetermined mmimum usage 
allowance; 

b. receive said request for additional usage allowance; 

c. allocate a subset of any unclaimed usage allowance fi*om said master wallet to 
said first shadow wallet. 

29. A computerized system as claimed in Claim 28 wherein said wallet server further comprises 
computer executable instructions to reclaim an unused portion of said usage allowance allocated 
to a second shadow wallet and reallocate said unused portion to said first shadow wallet. 

30. A computerized system as claimed in Claim 29 wherein said automatic reallocation reduces 
the niunber of automatic requests made by a given logical server for additional usage allowance. 

31. A computerized system as claimed in Claim 24 wherein said master wallet includes a set of 
conditions pertaining to the access of said master wallet that are passed onto any shadow wallets 
associated with said master wallet. 
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32. A computerized system as claimed in Claim 31 wherein said set of conditions are 
automatically determined by a product purchased by a user. 

33. A computerized system as claimed in Claim 32 wherein said set of conditions includes a 

validity period. 

34. A computerized system as claimed in Claim 24 wherein said wallet server further comprises 
computer executable instructions to, upon the failure of any of said plurality of logical servers, 
their associated logical datastores or said shadow wallets, hereinafter a failed logical component, 
create a new logical component to replace said failed component. 

35. A computerized system for resource management comprising: 

a. a computer readable datastore associated with a server, said server hereinafter 
referred to as a wallet server, wherein a master copy of a wallet comprising 
computer readable storage representing a usage allowance, hereinafter master 
wallet, is stored; 

b. a plurality of logical servers which are logical partitions of said wallet server; 

c. a plurality of computer readable logical datastores which are logical partitions of 
said datastore; 

wherein said wallet server fijrther comprises computer executable instructions to: 

- create said master wallet for a set of users; 

- configure each of said plurality of logical servers and their associated logical 

datastores for a subset of said set of users; 

- assign a service level to each of said logical servers; 

- allocate a plurality of independent subsets of said master wallet, prior to an 
event arrival including a request, each of said subsets hereinafter referred to 
as a shadow wallet, wherein each shadow wallet is associated with one of 
said plurality of logical servers and its associated logical datastore; 
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- determine a service level associated with a said request received by said 
system and distribute said request to a particular logical server associated 
with said service level and configure said particular logical server, to 
process a request received by said system for a first user from said subset of 
users against said shadow wallet associated with said first user. 

36. A computerized system for resource management comprising: 

a. a computer readable datastore associated with a server, said server hereinafter 
referred to as a wallet server, wherein a master copy of a wallet comprising 
computer readable storage representing a usage allowance, hereinafter master 

wallet, is stored; 

b. a plurality of logical servers which are logical partitions of said wallet server; 

c. a plurality of computer readable logical datastores which are logical partitions of 
said datastore; 

wherein said wallet server further comprises computer executable instructions to: 

- create said master wallet for a set of users associated with an account 
providing a bundled allowance; 

- configure each of said plurality of logical servers and their associated logical 

datastores for a subset of said set of users; 

- subdivide said master wallet into a plurality of independent shadow wallets, 
prior to an event arrival including a request, wherein each shadow wallet is 
associated with one of said plurality of logical servers and its associated 
logical datastore; 

- process a plurality of requests against said master wallet by configuring each 
of said plurality of logical servers, to process a said request received by said 
system for a given user from said subset of users against said shadow wallet 
associated with said given user. 
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37. A computerized system as claimed in Claim 36 wherein said wallet server further comprises 
computer executable instructions to set a flag, accessible by any of said plurality logical servers, 
to indicate a state relating to said master wallet. 

38. A computerized system as claimed in Claim 37 wherein said flag indicates that additional 
usage allowance is not available from said master wallet. 

39. A computerized system as claimed in Claim 38 wherem said wallet server further comprises 
computer executable instructions to set a corresponding flag on each of said shadow wallets 
derived from said master wallet to inform said associated logical servers that the master wallet is 
exhausted in order to limit repeated requests by said associated logical servers for additional 
usage allowance. 

40. A computerized system as claimed in Claim 37 wherein said master wallet includes a 
schedule for automatic periodic usage allowance replenishment which is associated with a 
product purchased by a user. 

41. A computerized system as claimed in Claim 36 wherein said wallet server further comprises 
computer executable instructions to configure said plurality of logical servers to process a query 
in isolation from said wallet server. 
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X. RELATED PROCEEDINGS APPENDK 
None. 
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